All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

I have read the CLA Document and I hereby sign the CLA

Thank you for this! Looking forward to it.

Merge this please, it's an essential piece of functionality.

This two commit, extends the /status panel to display which codex_home the project is currently running with.
In addition, several test and formatting improvements have been made to ensure consistency across snapshots and UI rendering.

Details

• Added the home field to the Status card data model and updated the label list to include a new “Home” row, formatted using format_directory_display for consistency with the Directory line.
• Implemented sanitize_field logic to normalize Home and Directory values in snapshot tests, ensuring that replacements maintain the correct card width.
• Updated snapshot sanitizer to apply the normalization logic to both Home and Directory fields.
• Regenerated all related status snapshots to include the new Home line with proper alignment.
• Ran just fmt, just fix -p codex-tui, and cargo test -p codex-tui to validate and format all changes.

CODEX_HOME: ~/codex

/status

╭────────────────────────────────────────────────────────────────────────╮
│  >_ OpenAI Codex (v0.0.0)                                              │
│                                                                        │
│  Model:            gpt-5-codex (reasoning high, summaries auto)        │
│  Home:             ~/.codex                                            │
│  Directory:        ~/Projects/opensource/codex/codex-rs                │
│  Approval:         on-request                                          │
│  Sandbox:          workspace-write                                     │
│  Agents.md:        ../AGENTS.md                                        │
│  Account:          API key configured (run codex login to use ChatGPT) │
│  Session:          xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx                │
│                                                                        │
│  Token usage:      0 total  (0 input + 0 output)                       │
│  Context window:   100% left (0 used / 272K)                           │
│  Limits:           send a message to load usage data                   │
╰────────────────────────────────────────────────────────────────────────╯

A folder named .codex was opened in the main project directory.
CODEX_HOME: project_folder_path/.codex

/status

╭────────────────────────────────────────────────────────────────────────╮
│  >_ OpenAI Codex (v0.0.0)                                              │
│                                                                        │
│  Model:            gpt-5-codex (reasoning none, summaries auto)        │
│  Home:             ~/Projects/opensource/codex/codex-rs/.codex         │
│  Directory:        ~/Projects/opensource/codex/codex-rs                │
│  Approval:         on-request                                          │
│  Sandbox:          read-only                                           │
│  Agents.md:        ../AGENTS.md                                        │
│  Account:          API key configured (run codex login to use ChatGPT) │
│  Session:          xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx                │
│                                                                        │
│  Token usage:      0 total  (0 input + 0 output)                       │
│  Context window:   100% left (0 used / 272K)                           │
│  Limits:           send a message to load usage data                   │
╰────────────────────────────────────────────────────────────────────────╯

github spec-kit asks you to set CODEX_HOME when using it in a project. This would make that unnessecary.

@kervel Yes, that's true; the goal is to create a project-specific conf structure. Under normal use, if there's no .codex folder in the project, the system will work as before without any impact.

The challenge with supporting an in-repo .codex folder for configuration (which I do believe is a good thing for sharing configuration across contributors to a project) is that, using the default workspace-write sandbox setting, that means that Codex could update its own config.toml file.

One could imagine a situation where someone tries to trick Codex into adding sandbox_mode = "danger-full-access" to .codex/config.toml in the repo such that the next time codex is invoked, it would operate without a sandbox.

Today, with Seatbelt on macOS, we have the ability to make, e.g., the .git folder within a repo read-only while the rest of the repo is writable, as verified here:

Though the Landlock/Seccomp sandbox we use on Linux does not support this today. My understanding is that it does not allow a subfolder (.git in this case) to have a more restrictive policy than the parent folder (the writable Git repo) unless the folders are on different filesystems.

All that is to say, before supporting such a feature, I think we need a reasonable mitigation for the scenario described above (be it sandboxing or in-repo config.toml supporting only a subset of the full set of config options).

Related: #2308.

@cemilcolak, after some internal discussion, we've decided to close this PR. We really appreciate that you took the time to implement this. This is a highly-requested feature, and we'd love to get it into the hands of codex users. However, as bolinfest mentions above, the difficult part is in working through the security and sandboxing implications of the feature. That's going to require some deep thought and design work. Once we have those questions answered and the requisite sandboxing enhancements in place, it should be straightforward to implement the code to handle project-local features. We can use your code as a good PoC (proof of concept).

@bolinfest @etraut-openai Thanks for the explanation. I’ve been using this feature for about 1.5 months and it’s been very helpful in practice. I understand your concerns, and I’ll also think more about the security side. I’m happy to help again once the design is ready.